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May It Please The Honorable Board: 

This is Appellants' Brief on Appeal from the final rejection of claims 1 - 14. 
Please charge any fee or credit overpayment for filing this Brief to Deposit Account No. 07- 
0832. Enclosed is a single copy of the Brief and a Petition for Extension of Time extending 
the deadline for filing the Brief by four months to expire on April 11, 2006. Appellants 
waive an Oral Hearing for this appeal. 



I, REAL PARTY IN INTEREST 

The real party in interest of Application Serial No. 09/980,354 is the Assignee of 

record: 

Thomson Licensing, S. A. 

46 Quai A. Le Gallo 

F-92100 Boulogne-Billancourt, 
************************^ 

Certificate of Mailing under 37 CFR 1.8 
L hereby certify that this, correspondency is being deposited with the U/Uted States EostaL 

Signature __^iQ^ j{!^Z^___. Date: ftpn I I o t **o(a 



CUSTOMER Nb. 24498 
Serial No.: 09/980,354 



PF990032 



France 

II. RELATED APPEALS AND INTERFERENCES 

There are currently, and have been, no related Appeals or Interferences regarding 
Application Serial No. 09/980,354 known to the undersigned attorney. 

i 

IIL STATUS OF THE CLAIMS 

Claims 1-14 are rejected and the rejection of claims 1 - 14 are appealed. 

IV. STATUS OF AMENDMENTS 

All amendments were entered and are reflected in the claims included in Appendix I. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

Independent claim 1 claims a method for determining a routing table in a 
communication network comprising buses connected by bridges, each bridge comprising 
two companion portals, a first portal being connected to a first bus and a second portal 
being connected to a second bus, each bus being identified by a unique bus identifier, each 
portal being identified by a unique portal identifier (page 1, lines 28-34; figs. 2-6, page 5, 
line 34 - page 6, line 8), said method comprising the steps of: (a) transmitting, by a given 
portal, routing table data stored by said given portal to a companion portal associated with 
said given portal and receiving, by said given portal, routing table data from the companion 
portal (page 2, lines 1-3; page 9, lines 13-14); (b) concatenating said routing table data 
received in step (a) with the contents of the routing table data stored by said given portal 
(page 2, lines 4-5; page 9, lines 15-18); (c) broadcasting said routing table data stored by 
said given portal on a local bus associated with the given portal (page 2, lines 6-10; page 9, 
lines 15-17); (d) receiving routing table data broadcast by other portals on the local bus and 
concatenating said received routing table data broadcast by other portals with contents of 
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the routing table data stored by said given portal (page 2, lines 6-10; page 9, lines 15-17); 
(e) repeating the above steps until routing data concerning all buses in the network has been 
received by said given portal (page 2, lines 11-12; page 9, lines 13-18). 

Independent claim 14 claims a portal device (P202, P203) adapted to be connected 
to a first communication bus (B201, B202) and adapted to be linked to a companion portal 
device (P202, P203) for connection to a second communication bus (B201, B202), the 
portal device comprising: a bus interface (101) for connection to said first communication 
bus; a switching fabric interface (102) for connection to said companion portal device; a 
memory (104) for storing routing table data; means for transmitting (105, 106, 107 and 
page 5, lines 20-26) routing table data stored in said memory to said companion portal, for 
broadcasting (PHY, LINK and page 5, lines 15-16) routing table data stored in said memory 
on said first communication bus, for controlling (103 and page 5, lines 30-32) said bus 
interface and switching fabric interface to receive or transmit routing table data, and for 
concatenating (104 and page 5, lines 30-32) received routing table data with data stored in 
said memory during successive receive and transmit cycles relating to routing table data for 
remote communication buses. 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The Examiner has rejected claims 1-4, 7-10 and 12-14 under 35 USC 102(b) as 
being anticipated by Tai, T., Gerla, M., "LAN Interconnection; A Transparent, Short-Path 
Approach" EEEE International Conference on Communications, 23-26, June 1991, pages 
1666-1670, vol. 3 ("Tai"). 

The examiner has rejected claims 5 and 6 under 35 USC 103(a) as being 
unpatentable over Tai and further in view of Garcia (US Published Application 
20020049561) 

The examiner has rejected claim 11 under 35 USC 103(a) as being unpatentable 
over TaTarid further inview of Oechsle (US Pat. No. 5570466) 

VII. ARGUMENT 

Rejection of claims 1-4, 7-10 and 12-14 under 35 USC 102(b) as being anticipated by Tai, 

T., Gerla, M., "LAN interconnection; a transparent, short-path approach" IEEE 
International Conference on Communications, 23-26, June 1991, pages 1666-1670, vol. 3. 

"A claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described, in a single prior art reference." Verdegaal 
Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 
1987). See MPEP 2131. 

Tai fails to disclose or suggest all of the limitations of Claims 1 and 1 1 and hence 
fails to anticipate claims 1 and 11, and the claims that depend therefrom, as a matter of law. 

Claim 1 

Independent claim 1 recites: 
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1. Method for determining a routing table in a communication network comprising 
buses connected by bridges, each bridge comprising two companion portals, a first portal 
being connected to a first bus and a second portal being connected to a second bus, each 
bus being identified by a unique bus identifier, each portal being identified by a unique 
portal identifier, said method comprising the steps of: 

(a) transmitting, by a given portal, routing table data stored by said given portal to 
a companion portal associated with said given portal and receiving, by said given portal, 
routing table data from the companion portal; 

(b) concatenating said routing table data received in step (a) with the contents of 
the routing table data stored by said given portal; 

(c) broadcasting said routing table data stored by said given portal on a local 
bus associated with the given portal; 

(d) receiving routing table data broadcast by other portals on the local bus and 
concatenating said received routing table data broadcast by other portals with contents of 
the routing table data stored by said given portal; 

(e) repeating the above steps until routing data concerning all buses in the 
network has been received by said given portal. 

Accordingly, claim 1 broadly encompasses a method for building a routing table by 
performing an iterative process that includes exchanging routing table data between two 
companion portals of a bridge, concatenating received routing table data with the routing 
table data of a given portal, exchanging the routing table data between portals connected to 
the same bus, concatenating the received routing table data with routing table data of the 
given portal, and repeating these steps until the routing data for all of the buses in the 
network have been received. 

The Tai reference is directed to an entirely different problem within a different 
context and fails to disclose or suggest each of the limitations recited in claim 1. In 
particular, the present invention is directed to the problem of determining a routing table in a 
network of buses that are interconnected by bridges, each of the bridges comprising two 
companion portals connected to respective buses. By contrast, Tai is directed to a new 
intelligent MAC layer device called a brouter that allows all links in a network to be 
effectively utilized and shortest paths to be used. The brouter ID must be unique within the 
network and each port is uniquely identified within a brouter. 
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The nature of determining a routing table in a context of a network of buses is quite 
different in from building routing tables in a context of a Local Area Network (LAN). For 
example, a bus is identified by its own address, whereas a LAN has no specific address 
because each element of the LAN has its own MAC address. In a bus the address for routing 
is shared by all nodes connected to the bus and the identifier of all nodes is updated at the 
reset of the bus. Whenever a new node appears or disappears on a bus, there i$ a bus reset. 
Thus, in the environment of the invention, an update of routing tables is useful only when a 
bus reset occurs. On a LAN, the problem is quite different because the routing tables are 
continuously updated. Tai mentions this point in the last paragraph of section 2.1 ("The 
construction of the forwarding database is essentially a background process in a brouter") 

In addition, the structure of a LAN and a bus network of the present invention are 
very different. In the context of the invention, bridges interconnect buses and routing tables 
contain bus addresses. In other words, bridges connecting the buses store and update routing 
tables containing the address of the element (bus) to which they are connected. In a LAN, 
routing tables contain node addresses, the nodes belonging to a LAN interconnected by the 
routers. In other words, routers in a LAN do not store or update routing tables containing 
address of the element (LAN node) to which they are not directly connected. Rather, there is 
a LAN infrastructure between LAN nodes and LAN routers. Thus, the physical link 
between a bridge and the buses according to the invention is very different from the physical 
link between a LAN router and LAN nodes. 

In view of the differences above and the description of the process in Tai, it is clear 
that Tai fails to disclose or suggest the limitations or claim 1. The method of Tai for 
building a routing table involves the steps of building a delay table at each brouter, 
exchanging these delay tables between the brouters, and computing a routing table at each 
port based on the delay tables. Tai also addresses the different problem of determining a 
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unique LAN ID for each LAN, and building a mapping table between all station IDs and 
their LAN ID. This process is completely different from the method of the present 
invention, which involves exchanging routing tables between portals of a bridge and 
concatenating the exchanged routing tables in an iterative process to generate the routing 
tables. 

The specific steps for determining the routing table is described in paragraph 2.2, 
which states in part, "more specifically, at brouter b, say, the tables Delay b (i) and 
OutPortb(i) are kept ..." and gives the algorithm to compute these tables: Delay b (i) = 
min b <{Delay b *(i) + l(b, b')}. After computing the tables, each brouter b hosts its own 
Delay b (i) table. Then, an exchange of the Delay table occurs between brouters, e.g., "... the 
forwarding database at each port is constructed by exchanging the delay tables periodically 
..." Once these delay tables have been received, the forwarding database is computed using 
the specified algorithm, e.g., "[a]fter receiving the delay tables, each port p, say, of brouter 
b calculates its own forwarding database indexed by destination LAN id as follows ..." 

Tai fails to disclose or suggest the limitation of "... transmitting by a given portal, 
routing table data stored by said given portal to a companion portal associated with said 
given portal and receiving, by said given portal, routing table data from the companion 
portal." This limitation relates to an exchange of routing table data at the level of each 
bridge, particularly, between the different routing tables located at companion portals 
of a particular bridge. 

Page 1667 of Tai is cited as disclosing this limitation. However, the portion of Tai 
cited by the Examiner relates to an algorithm to build a mapping table and a scheme to 
broadcast a list of local stations on a LAN (obtained by intersecting the lists of station ids 
on all the ports which are directly connected to that LAN (inter-bridge)). This portion does 
not disclose or suggest the feature of exchanging routing tables between portals of a bridge. 
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Furthermore, applied to the context of Tai, this limitation of claim 1 would require 
an exchange in a brouter between routing tables maintained at the port level of the 
brouter. However, Tai says nothing regarding the exchange of data within a particular 
brouter, instead, Tai teaches the exchange of data between ports of different brouters on 
a connected LAN. 

Tai also fails to disclose or suggest the limitation of"... concatenating said routing 
table data received in step (a) with the contents of the routing table data stored by said 
given portal." This limitation relates to the combining of routing table data in a given 
portal. Nowhere does Tai disclose or suggest the feature of combining routing table data by 
concatenation in a giverTportal. ~ " - - — 

The portion of Tai cited by the examiner as disclosing this feature, namely Column 
1, page 1669, in fact concerns the problem of building a mapping table between station id 
and LAN id, not routing table data, and is not at all concerned with building of a routing 
table. This problem does not arise in the context of the present invention where the 
network addresses are the concatenation of the bus ID and the GUID of the destination on 
the bus. The cited paragraph actually teaches intersecting lists to obtain a list of stations 
IDs on all ports that are directly connected to that LAN. Intersecting lists to obtain a list of 
station IDs is entirely different from concatenating routing table data, and Tai simply does 
not mention or suggest the concatenation of table data as recited in claim 1. 

Tai also fails to disclose or suggest the limitation . . (c) broadcasting said its own 
routing table data on the portal's local bus associated with the given portal. . . " The 
examiner cites page 1668, col. 2, and page 1668, col. 1, as disclosing the feature recited in 
step (c). Applicants submit that the cited portion fails to disclose or suggest this feature. 
Actually, page 1668, col. 2 discusses an algorithm to determine a LAN id, not a method to 
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build a routing table, and page 1668, col. 1 concerns the delay table used before the step of 
computing the routing table, The cited portions are not related to routing table data. 

Tai also fails to disclose or suggest the limitation "... (d) receiving routing table data 
broadcast by other portals on the local bus and concatenating said received routing table 
data broadcast by other portals with contents of the routing table data stored by said given 
portal." The examiner cites page 1668, col. 1 as disclosing this step. Applicants 
respectfully disagree that the cited portions disclose the recited limitation. First of all, the 
shortest path is not added to routing database, the delay table is used to compute the routing 
database. Tai does not appear to describe any operation that could be seen as a 
— cowatenatioriof Touting table dStaTAccdrding to the invention, the use of term 
concatenation makes clear that the received routing table data are just added to the table 
(see for example, page 9, lines 14-16 and lines 25-26). 

Finally, Tai fails to disclose or suggest the limitation "... repeating the above steps 
by said given portal until routing data concerning all buses in the network has been received 
by said given portal." This limitation refers to the fact that steps (a), (b), (c) and (d) are 
executed iteratively until the routing table data concerning all buses has been received. 

The Examiner cites page 1668, column 2, paragraph 3.1 of Tai as disclosing this 
step. Applicants disagree and submit that the cited portion does not disclose or suggest this 
step. The cited paragraph 3.1 does not concern the building of routing table, and 
furthermore, it does not describe any iterative process. It describes the computation of 
LAN id, which is done in one step, and indicates that this step is conducted periodically to 
account for changes in the network. In particular, this paragraph states that "by periodically 
exchanging the concatenated ids among brouters attached to the same LAN, the up to date 
LAN id is determined and the master brouter is elected." This passage means that a process 
of electing the minimum id as the LAN id is conducted periodically to adapt to changes in 
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the network, for example, for brouter failure. This passage does not disclose or suggest 
conducting an iterative process of building a routing table until the routing table data 
concerning all buses has been received. Therefore, applicants submit that Tai does not 
disclose or suggest the iteration feature as recited in step (e) of claim 1. 

In summary, Tai teaches a system that builds delay tables, exchanges the delay 
tables and computes the routing tables from the delay tables. For the reasons discussed 
above, the steps of this process are entirely distinguishable from the steps for determining a 
routing table in a network comprising buses connected by bridges as recited in claim 1. 
Therefore, applicants respectfully submit that Tai fails to disclose or suggest every 
limitation of claim 1, and as such, request reconsideration and withdrawal of this rejection 



CLAIM 14 

Independent claim 14 recites: 

14. Portal device adapted to be connected to a first communication bus and 
adapted to be linked to a companion portal device for connection to a second 
communication bus, said portal device comprising: 

- a bus interface for connection to said first communication bus; 

- a switching fabric interface for connection to said companion portal device; 

- a memory for storing routing table data; 

- means for transmitting routing table data stored in said memory to said 
companion portal, for broadcasting routing table data stored in said memory on said first 
communication bus, for controlling said bus interface and switching fabric interface to 
receive or transmit routing table data, and for concatenating received routing table data with 
data stored in said memory during successive receive and transmit cycles relating to routing 
table data for remote communication buses. 



Independent claim 14 is directed to a portal linked to a companion portal and 
coupled to a bus, wherein the portal is adapted to determine the routing table in accordance 
with the method of claim 1. For the reasons discussed hereinabove with respect to 
independent claim 1, applicants submit that the system of Tai fails to disclose or suggest at 
least the limitation of "... means for transmitting routing table data stored in said memory to 
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said companion portal, for broadcasting routing table data stored in said memory on said 
first communication bus, for controlling said bus interface and switching fabric interface to 
receive or transmit routing table data, and for concatenating received routing table data with 
data stored in said memory during successive receive and transmit cycles relating to routing 
table data for remote communication buses." 

As discussed above, Tai is directed to a system wherein a brouter builds delay tables, 
exchanges delay tables, and computes routing tables from the delay tables. Tai does not 
disclose or suggest means for transmitting routing tables to a companion portal or means for 
concatenating received routing table data with data stored in memory as recited in claim 14. 
FoTllT^eason^disc^ the cited portions of Tai do not disclose or suggest 

these features. Therefore, applicants submit that Tai fails to disclose each and every 
limitation of claim 14, and as such, claim 14 is not anticipated by Tai, and respectfully 
request reconsideration and withdrawal of this rejection. 

Rejection of Claims 5 and 6 under 35 USC 103(a) over 
Tai in view of Garcia (U.S. Published Application 20020049561), 

The cited prior art fails, in any combination, to render pending claims 5 and 6 

unpatentably obvious under 35 U.S.C. 103(a). To establish a prima facie case of 

obviousness, all of the recited claim limitations must be taught or suggested in the prior art. 

See, M.P.KP. 706.02Q); see also, M.P.E.P. 2143.03 citing In re Royka, 490 F.2d 981, 180 

USPQ 580 (CCPA 1974) ("All words in a claim must be considered in judging the 

patentability of that claim against the prior art") and In re Wilson, 424 F.2d 1382, 1385, 

165 USPQ 494, 496 (CCPA 1970). 

As discussed below, the Tai and Garcia, both singly and in combination, fail to teach 

or suggest all of the limitations of Claims 5 and 6 - and hence fail to render claims 5 and 6 

unpatentable as a matter of law. 
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CLAIMS 5 and 6 

Claim 5 depends from claim 1 and further recites that the routing table transmitted or 
broadcast by the given portal contains the entire routing table. Claim 6 depends from claim 
5 and further recites that the iteration steps (a)-(e) stops when the routing tables received 
from the companion portal and local portals only contain data that is redundant with the 
routing table stored in the given portal. 

Garcia is cited as teaching that the routing table data transmitted or broadcast by a 
given portal contains the entire routing table. Even assuming arguendo that Garcia teaches 
such/a feature," applicants submit that claims 5 and 6, which depend from claim 1, is 
patentably distinguishable over the combination of Tai and Garcia because Garcia fails to 
cure the defect of Tai as applied to claim 1. Applicants submit that Garcia does not teach or 
suggest the limitations of claim 1 discussed above. Therefore, even if Garcia teaches the 
alleged feature, the combination of Tai and Garcia still fail to teach or suggest the additional 
limitations recited in claim 1. 

The examiner states in the advisory action that M [t]his problem solving methodology 
of Garcia is of a paramount importance for curing the deficiencies of Tai and not the type of 
network." Applicants submit that such an assertion fails to address the deficiencies of Tai 
with regard to claim 1. Clearly, in order for 35 USC 103(a) to be properly applied, the 
combination of Tai and Garcia must teach or suggest each and every limitation of claim 5, 
which includes the limitations of claim 1. The fact that Garcia discusses a particular 
methodology for curing the deficiencies of Tai does not overcome the deficiencies of Tai as 
applied to claim 1. Therefore, applicants submit that claims 5 and 6, which depend from 
claim 1, are patentably distinguishable over the combination of Tai and Garcia, and 
respectfully request reconsideration and withdrawal of this rejection. 
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Rejection of Claim 11 under 35 USC 103(a) over 
Tai in view of Oechsle (U.S. Pat No. 5570466). 

Claim 11 depends from claim 1 and further recites that a selected path to a- given 
remote bus is a function of the bandwidth of portals on the selected path. 

Oechsle is cited as teaching selecting the path to a given remote bus as a function of 
the bandwidth of portals on the path. However, even assuming arguendo that Oechsle 
teaches the above, the combination of Tai and Oechsle still fails to cure the deficiencies of 
Tai as applied to claim 1. As such, the combination of Tai and Oechsle fails to teach or 
suggest every limitation of claim 11, which depends from claim 1, and thus, claim 11 is 
patentably distinguishable over the combination of Tai and Oechsle, and respectfully request 
reconsideration and withdrawal of this rejection. 
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VIII CONCLUSION 

In view of the above, applicants submit that the pending claims are not anticipated or 
rendered obvious in view of the cite references. Accordingly it is respectfully requested that 
the rejection of Claims 1-14 be reversed. 



Respectfully submitted, 
Y. Legallais, et al. 

By: &*MJ 

Paul P. Kiel 
Attorney for Applicants 
Registration No. 40,677 
(609)734-6815 



Patent Operations 
Thomson Licensing Inc. 
P.O. Box 5312 
Princeton, NJ 08543-5312 

Date //rU 
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APPENDIX I - APPEALED CLAIMS 

1. Method for determining a routing table in a communication network comprising 
buses connected by bridges, each bridge comprising two companion portals, a first portal 
being connected to a first bus and a second portal being connected to a second bus, each 
bus being identified by a unique bus identifier, each portal being identified by a unique 
portal identifier, said method comprising the steps of: 

(a) transmitting, by a given portal, routing table data stored by said given portal to 
a companion portal associated with said given portal and receiving, by said given portal, 
routing table data from the companion portal; 

(b) concatenating said routing table data received in step (a) with the contents of 
the routing table data stored by said given portal; 

(c) broadcasting said routing table data stored by said given portal on a local 
bus associated with the given portal; 

(d) receiving routing table data broadcast by other portals on the local bus and 
concatenating said received routing table data broadcast by other portals with contents of 
the routing table data stored by said given portal; 

(e) repeating the above steps until routing data concerning all buses in the 
network has been received by said given portal. 

2. Method according to claim 1, wherein 

- the routing table data transmitted by said given portal during the first iteration 
of the step (a) comprises an identifier of the given portal and an identifier of the given 
portal's local bus; 

- the routing table data received by said given portal from the companion portal 
during the first iteration of step (a) comprises an identifier of said companion portal and an 
identifier of the companion portal's local bus. 

3. Method according to claim 2, wherein said routing table data transmitted, 
respectively received, by said given portal comprises the given portal's identifier, 
respectively the identifier of the given-portal's companion portal. 

4. Method according to claim 2, wherein the routing table of a portal comprises 
the identifiers of remote buses, and for each remote bus, the identifier of the portal local to 
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the remote bus having initially transmitted the remote bus identifier, the depth of the remote 
bus compared to the bus local to the given portal, and the identifier of the local portal 
having broadcast the routing table data comprising the remote bus identifier on the local 
bus. 

5. Method according to claim 1, wherein the routing table data transmitted or 
broadcast by said given portal contains the entire routing table. 

6. Method according to claim 5, wherein the given portal stops iterating the 
steps (a) to (e) when the routing tables received from the companion portal and local portals 
contain only data which is redundant with the given portal's own routing table. 

7. Method according to claim 1, wherein the routing table data transmitted or 
broadcast by the given portal comprises only a part of the routing table which was not 
transmitted or broadcast by said given portal during a previous step. 

8. Method according to claim 7, wherein the given portal stops iterating the 
steps (a) to (e) when the given portal did not receive routing data during a previous 
iteration. 

9. Method according to claim 1, wherein the concatenation steps include 
selection of a unique path from the bus local to the given portal to any remote bus and 
deletion of non-selected paths from the routing table of the given portal. 

10. Method according to claim 9, wherein said selected path to a given remote 
bus is a function of portal identifiers stored in the routing table for said given remote bus. 

11. Method according to claim 9, wherein said selected path to a given remote 
bus is a function of the bandwidth of portals on said selected path. 

12. Method according to claim 9, wherein said selection is made among the 
shortest paths to the remote bus, paths of greater length being deleted from the routing 
table. 
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13. Method according to claim 1, wherein a routing table is simplified for the 
purpose of routing messages to contain a list of remote bus identifiers and for each remote 
bus whether the given portal shall forward a message from the bus local to the given portal 
to its companion portal. 

14. Portal device adapted to be connected to a first communication bus and 
adapted to be linked to a companion portal device for connection to a second 
communication bus, said portal device comprising: 

- a bus interface for connection to said first communication bus; 

- a switching fabric interface for connection to said companion portal device; 

- a memory for storing routing table data; 

- means for transmitting routing table data stored in said memory to said 
companion portalrfor broadcasting routing table data stored in said memory on said first 
communication bus, for controlling said bus interface and switching fabric interface to 
receive or transmit routing table data, and for concatenating received routing table data with 
data stored in said memory during successive receive and transmit cycles relating to routing 
table data for remote communication buses. 
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